Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/answers/comp/amiga/introduction/part1

Text File | 1994-03-30 | 47.0 KB | 1,071 lines

Path: bloom-beacon.mit.edu!hookup!news.moneng.mei.com!howland.reston.ans.net!EU.net!Germany.EU.net!netmbx.de!zrz.TU-Berlin.DE!zib-berlin.de!news.th-darmstadt.de!News.Uni-Marburg.DE!news.belwue.de!iptc!newsserv.zdv.uni-tuebingen.de!zrawi01
From: [e-mail] (Jochen Wiedmann)
Newsgroups: comp.sys.amiga.introduction,comp.sys.amiga.misc,comp.sys.amiga.programmer,comp.answers,news.answers
Subject: Amiga FAQ (Frequently asked questions) (Part 1 of 2)
Supersedes: <[e-mail]>
Followup-To: comp.sys.amiga.introduction
Date: 29 Mar 1994 19:55:04 GMT
Organization: InternetNews at ZDV, University of Tuebingen, Germany
Lines: 1050
Approved: [e-mail]
Distribution: world
Expires: Saturday, 16 Apr 94 21:42:28 (Z)
Message-ID: <[e-mail]>
Reply-To: [e-mail] (Jochen Wiedmann)
NNTP-Posting-Host: mailserv.zdv.uni-tuebingen.de
Summary: Frequently asked questions on the Amiga.
         New users should read this!
Originator: [e-mail]
Xref: bloom-beacon.mit.edu comp.sys.amiga.introduction:2623 comp.sys.amiga.misc:27700 comp.sys.amiga.programmer:27446 comp.answers:4344 news.answers:16993

Posted-By: auto-faq 2.4
Archive-name: amiga/introduction/part1
Last-modified: 29-Mar-1994


      Frequently asked questions (FAQ) concerning the Amiga. [1/2]
      ------------------------------------------------------------

Below you find a list of frequently asked questions. It should especially
be for new users but perhaps experienced users may find something too.
This is part 1, the second begins with chapter 5.

It is in Ascii format to be easily read by everyone. It is also available
in AmigaGuide and Dvi format as part of the Amiga-FAQ archive. (File
text/docs/AmigaFAQxxxxxx.lha on any Aminet site, where xxxxxx is the date
of the last version.)

Please note the following:

  - Changes since the last posting are marked with a
    !    changed this line/section, respectively
    +    added this line
    <    removed something before this line

  - An index is at the bottom of part 2. If this still doesn't help:
    E-mail me, probably I can include an answer into the FAQ.

  - Suggestions, contributions, critics and beer bottles are very
    welcome. :-) Send them to:

        Jochen Wiedmann
        Am Eisteich 9
      72555 Metzingen (Germany)
        Tel. 07123 / 14881

        Internet: [e-mail]

===========================(Cut here)=========================================

  Amiga-FAQ
  *********

     This document lists some frequently asked questions and trys to give
  answers.  Is intention is to help new users and to reduce the amount of
  news that most experienced users don't like to read anymore.

     Please notice that there are many questions that aren't answered yet,
  even more: Whole sections that remain empty! I feel that I cannot give
  satisfying answers. So it's your turn: Fill the gaps and tell me what i
  should include into this document!


  Disclaimer

  1 CPU, Custom chips, RAM and other stuff
    1 What are the 68EC020 and the 68EC030?
    2 What's an FPU?

  2 The Operating System
    1 Can I use another Kickstart than the builtin?

  3 Programming
!   1 What documentation do I need as an Amiga programmer?
    2 What is CATS?
!   3 Where do I get the Amiga includes?
    4 How do I become a developer?
!   5 What compilers (assemblers) are there?
    6 Those never working Esc sequences!
    7 Is it possible to use AmigaBasic on the A1200?
    8 How do I localize my program?
    9 How to obtain a pointer to a console's window
    10 What are pragmas?
    11 Where do I find the function xxx?

  4 Applications
    1 Text Editors
    2 What word processors are there?
    3 Desktop Publishing
    4 What is TeX and where can I get it?
    5 Are there any Postscript interpreters?

  5 How about Graphics?
    1 What are chunky and planar displays?
    2 What is doublebuffering?
    3 What monitors will work on my Amiga 1200/4000?
    4 How do I switch between PAL and NTSC?

  6 Emulators
    1 Can I run Unix on my Amiga?
    2 Is it possible to use the Amiga as X11 terminal?

  7 Miscellaneous
    1 Is there any unix version of LhA?
    2 What are files ending with ...?
    3 Is there a Stacker-like utility to pack my hard drive?
    4 Where do I get Fish disk xxx?

  8 Where and how do I get Software?
    1 Files and databases on freely distributable software
    2 A collection of tests
    3 Getting files from a FTP server
    4 Getting files from a Mail server
    5 The Fish disks
      1 The Amiga Library disks
      2 The Fresh Fish CD-Roms
    6 How do I Read and write MS-Dos disks?
    7 How do I split large files?

  The Amiga-FAQ archive

  Contributions

  Credits

  Index



  Disclaimer
  **********

     This document is

       Copyright (C)  Jochen Wiedmann
                       Am Eisteich 9
                 72555 Metzingen (Germany)
                       Tel. 07123 / 14881
                       Internet: [e-mail]

     Permission is granted to make and distribute verbatim and modified
  copies of this document following the terms of the "GNU General Public
  License" provided the copyright notice and this permission notice are
  preserved on all copies.

     The author gives *absolutely no* warranty that the answers given
  here are correct or usable. Many of them were contributed by other users
  and I cannot even make marginal checks. If you think that something
  should be changed, please tell me. Suggestions, contributions, new
  answers, critics, flames (oh, how I like this `nil:' :-) are rather
  welcome.  See Contributions.

  1 CPU, Custom chips, RAM and other stuff
  ****************************************

     This chapter contains questions concerning the Amiga-Hardware.

  1.1 What are the 68EC020 and the 68EC030?
  =========================================

     Motorola, the company producing the 680x0 family offers crippled
  versions of their processors. They are a little bit cheaper than the
  originals, that's why Commodore decided to build the 68EC020 into the
  A1200 and the 68EC030 into the A4000/030.

     The difference between the 68020 and the 68EC020 is that the latter
  can address just 16Mb of memory. That's why the A1200 cannot have more
  that 10 Mb RAM. In most cases you will not notice the difference.

     This is not the case for the 68EC030: Many owners will notice that
  the 68030 has an MMU and the 68EC030 doesn't have. There are some
  important programs depending on an MMU, for example Enforcer (a
  debugging utility), GigaMem (a program to emulate virtual memory) or
  all current Unix versions (see Unix). Other Amigas than the A4000 and
  the A3000 need an additional processor card to run these.

     Finally the 68LC040 is a 68040 without FPU. See FPU.

  1.2 What's an FPU?
  ==================

     The first 680x0 processors (upto 68030) could process integers only.
  Floating point operations had to be emulated by the software. An FPU is
  a chip (or part of a chip) that can process floating point operations, a
  mathematical coprocessor.

     One separates three FPU types on the Amiga: The 68881, 68882 and the
  68040's internal FPU. The 68882 is up to 1.5 times faster than the
  68881, because it is splitted in two parts: A conversion unit (the
  FPU's are using an 80 bit format internally) and the arithmetic unit.
  The 68040's internal FPU adds a pipeline, but misses the trigonometric
  instructions of the others. These are still emulated by the software,
  68040.library for example.

     Special programs (Raytracing, DTP, Mathematics, TeX) are offered in a
  special coprocessor version which are up to 50 times faster than the
  original versions.

     Michael Kaiser ([e-mail])

  2 The Operating System
  **********************

     This chapter handles questions concerning the operating system,
  Kickstart as well as the Workbench.

  2.1 Can I use another Kickstart than the builtin?
  =================================================

     First let's drop some words on the Kickstart's Copyright: This
  belongs to Commodore, you *must* not use Kickstarts, without the right
  to do it!  Especially it isn't allowed to make an image of anyone
  else's Kickstart and run this on your own Amiga. (I even doubt that it
  is allowed to do this on your own Amigas, if you have more than one.)

     But of course it is possible and allowed for some people, developers
  for example.  There are two different ways, a hardware solution and a
  software solution.  The former is to buy a card which can hold two or
  more Kickstart ROMS and allows to select between when the System is
  booting.

     The software solution needs a program (softkicker) and an image of
  the ROM. The softkicker allocates RAM, loads the ROM image into the
  allocated memory and reboots. Of course you have less RAM after the
  Reboot: 256Kb when running Kickstart 1.2 or 1.3 and 512Kb for Kickstart
  2.0 or higher.

     There are different Softkickers, some of them needing a MMU (see
  68EC0xx). A nearly perfect solution seems to be `kick13' (Aminet,
  directory `util/misc') because it has the ROM image included. (With
  Commodores agreement!) For newer Kickstarts I recommend SKick 3.43
  (Aminet, directory `os20/util') because it doesn't need a MMU and
  supports many different Kickstarts. It is rather easy to create the ROM
  image using the following program:

           #include <stdio.h>

           #define kickorig 0xf80000   /*  0xfc0000 for Kick 1.2 und 1.3   */
           #define kicklen  0x080000   /*  0x040000 for Kick 1.2 und 1.3   */

           void main(int argc, char*argv[])
             { FILE *fh;

               if ((fh = fopen("kickstart.file", "w"))  !=  NULL)
                 { result = fwrite(kickorig, kicklen, 1, fh);
                 }
               fclose(fh);
             }

  3 Programming
  *************

     This chapter handles problems arising for programmers only.

! 3.1 What documentation do I need as an Amiga programmer?
! ========================================================

     The best information available are the RKMs (ROM Kernel Manuals), 3rd
  edition, by Commodore, published by Addison-Wesley:
       The Amiga ROM Kernel Manual:  Libraries, ISBN 0-201-56774-1
       The Amiga ROM Kernel Manual:  Devices, ISBN 0-201-56775-X
       The Amiga ROM Kernel Manual:  Includes and Autodocs, ISBN
                                                            0-201-56773-3
       The Amiga Hardware Manual, ISBN 0-201-56776-8
       The Amiga User Interface Style Guide, ISBN 0-201-57757-7

  Especially the RKM: Libraries is a must. The RKM: Includes and Autodocs
  isn't that much worth: Better get the same stuff on disk instead to
  have it online.  See Includes.

     AmigaDOS isn't included in these books. The Autodocs give much
  information, but to go deeper you probably need
       The AmigaDOS Manual, 3rd Edition, ISBN 0-553-35403-5
     published by Bantam Books.

     Another good choice is
       The Amiga Guru Book

  by Ralph Babel. The book starts with a survey on different aspects of
  programming the Amiga. (About 250 pages) Useful for beginners are the
  sections on the Amiga's data types (not to be confused with the 3.x
  DataTypes used by MultiView, for example), the Includes and the
  amiga.lib. But even experienced programmers will find useful things
  here that are missing in the RKMs.  But the largest part are about 500
  pages on AmigaDOS and, as I think, the most important, because AmigaDOS
  is the worst officially documented part of the OS. The book is rather
  concise and hence not as easy to read as the RKMs, but I recommend it
  as an addition and instead of the AmigaDOS manual.  (Not, however, a
  replacement for the Libraries and Devices, which aren't covered here.)
  Unfortunately the book has no ISBN and is available in special stores
  only. But there are some mail order companies which offer it for about
  50$ and which accept credit cards:

!      Hirsch & Wolf OHG; Mittelstrasse 33; D-56564 Neuwied; Germany
!      Voice: [phone]; Fax: [phone]
!      E-Mail: <[e-mail]> (fax preferred)
       (Eurocard/Mastercard/VISA)

!      Periscope; Attn: Cody Lee; 1717 W Kirby Ave; Champaign, IL 61821, USA
!      Voice: [phone]; Fax: [phone]
!      E-Mail: <[e-mail]>
!
!      Someware; 27 rue Gabriel Peri; 59186 Anor; France
!      Voice: [phone]; Fax: [phone]
!      E-Mail: <[e-mail]>

  3.2 What is CATS?
  =================

     This is a department at Commodore West Chester which was formerly
  named `Commodore Amiga Technical Support' and was later renamed
  `Commodore Application and Technical Support'. These are people that
  work independently of Engineering, but close together with them, and try
  to help developers outside of Commodore to create nice Amiga
  applications, software or hardware. To achieve this, CATS has gathered
  a lot of informations and tools, on floppy, CD, or paper. Much of this
  material is also available to the general public. (1) But don't mix
  this up with some sort of Hotline for everyone!

     For Americans the address to get this material is
           CATS - Developer Applications
           Commodore
           1200 Wilson Drive
           West Chester, PA. 19380

  for all Europeans it's a company in Germany:
           Fa. Hirsch & Wolf
           Mittelstr. 33
           56564 Neuwied
           Tel. [phone]

     Dr. Peter Kittel, [e-mail]

     ---------- Footnotes ----------

     (1)  Which means: For Non-Developers.

! 3.3 Where do I get the Amiga includes?
! ======================================

     The only legal way to get the includes and autodocs (and you *should*
  get them, they are *very* useful!) is to become a developer (see
  Developer) or to buy the `NDU' (Native developers update kit, also
  known as `NDUK' or `NDK'), which is offered by CATS. They cost about
  30$ plus shipping and this seems to me to be a fair price. See CATS.
  The current version is 3.1.

     If you need only the includes, you could get them as well with a
! compiler (commercial compilers only) or by getting the Fresh Fish CD.
! See Fish CD.

  3.4 How do I become a developer?
  ================================

     You need the `ADSP' (Amiga Developer Support Program) documents. To
  get this write a letter to your local Commodore branch asking for these
  documents.  Everything else should be explained there. The german
  address (for the US address see CATS) is
           Commodore
           Lyoner Strasse 38
           60528 Frankfurt
     There are three different developer versions:
  *Registered*
       developers get access to the adsp-Net (kind of a
       Commodore-internal Usenet), which makes it possible to discuss
       problems with other developers, Commodore engineers included.
       Registered developers pay about 80$ per year, plus initial 30$
       initially.

  *Certified*
       developers seem to me the most interesting claass: They have the
       possibility copy the most beta versions of the system software
       (Kickstart and Workbench) and the respective Includes and
       AutoDocs. (Not all beta versions and especially no beta hardware.)
       You pay about 250$ per year plus 50$ initially for this.

  *Commercial*
       developers finally have in most details the same as certified
       developers, but may expect to get more beta versions and sooner,
       included beta hardware (This has *not* always been so in the
       past.), hencethey pay about 400$ plus 50$ initially.

  The above describes the prices and the situation in Germany and might be
  different elsewhere. Especially not all Commodore branches offer the
  registered status. A tip is to build a group of users and become a
  developer group, so the costs are reduced.

     All developers have to sign the so called`NDA' (non disclosure
  agreement), with which they accept not to give the received
  informations to unauthorized people.

! 3.5 What compilers (assemblers) are there?
! ==========================================

     There is a lot of programming languages on the Amiga, commercial as
  well as freely distributable. I will enumerate only those that I know
  or which seem it worth to me otherwise.

  *Assembler*
       All C-compilers have an Assembler included. Freely distributable
       are A68K and PhxAss (directory `dev/asm' on Aminet or Fish disks
       521 and 906)

  *C*
  *C++*
       Freely distributable C-compilers are `gcc' (which has its own
       directory `dev/gcc' on Aminet) and the evaluation version of
       `Dice' (for example per FTP from `ftp.uni-paderborn.de', directory
       `/news/comp.binaries.amiga/volume91/languages' or on Fish disk
!      491).  The advantage of `gcc' is that you find `gcc' versions all
!      over the world and on all computer systems. Another advantage is
!      that C++ is included into `gcc'! But it is slow and needs 4Mb of
!      RAM or more.

       Commercial C compilers are `Aztec-C' and `SAS-C'. I cannot
       recommend `Aztec-C', because the compiler doesn't seem to get
       further development. It should be remarked that the commercial
       compilers have especially wonderful debugging utilities (Source
!      level debuggers!) that the others are missing.  SAS-C has a
!      crosscompiler included, which translates C++ to C and supports the
!      source level debugger too.  Dice is the cheapest and fastest of
!      them, but SAS offers a students account and an update service
!      (even for owners of other compilers) which isn't very expensive.

       Comeau C++ is a crosscompiler like SAS-C++. That wouldn't be a
       problem, but Comeau C++ doesn't have a C compiler included.  You
       need SAS-C, Aztec-C or Dice additionally. But it supports the
       newest standards. And like gcc it runs on many platforms. Maxxon
       C++ is offered in Germany. I cannot say anything on it. Both
       compilers are commercial.  Comeaus address is:
                Comeau computing
                91-34, 120th Street
                Richmond Hill, NY, 11418-3214
                USA

                EMail: Greg Comeau, [e-mail]

  *Forth*
       JForth is said to be an excellent Amiga port of Forth. Among its
       advantages are object oriented extensions, full Amiga interface
       and an application generator. It is available from:
                Delta Research
                P.O. Box 151051
                San Rafael, CA   94915-1051

                Phone: [phone]
                EMail: Phil Burk, [e-mail]
                       Mike Haas, [e-mail]

  *Fortran*
       (Sigh! Still people who need it :-<) Freely distributable are BCF
       (Fish disk 470) and f2c, a Fortran to C converter (Aminet,
       directory `/dev/misc'). A commercial compiler is offered from
       ABSoft. All these are Fortran 77 compilers, I don't know any
       Fortran 90 compiler on the Amiga.

  *Lisp*
       Freely distributable Lisp interpreters are XLisp (Fish disk 181)
       and OakLisp (Fish disks 519 and 520) and CLISP
       (`/pub/lisp/clisp/binaries/amiga' at the server `ftp
       ma2s2.mathematik.uni-karlsruhe.de'). Lisp compilers are Gambit
       (Fish 764 and 765) and Scheme-to-C (Fish disks 556, 557 and 558).
       A mailing list is available too: Send a mail with the word
       `Subscribe' to `[e-mail]'.

  *Prolog*
       `/dev/lang/UNSWProlog.lha' and `dev/lang/sbp3_1e.lha' on Aminet as
       well as `SBProlog' on Fish disk 141 and `SBProlog' on Fish disk
       145 are freely distributable Prolog interpreters.

  *Modula-2*
       M2Amiga is offered in Europe, Benchmark Modula-2 in the U.S. Both
       are said to be very good, have a powerful souurce-level-debugger,
       a large library.  Especially M2Amiga has great support by a german
       user-group (AMOK) which for example offers own PD disks.

       M2Amiga is offered by:
                A+L AG
                Daderiz 61
                2540 Grenchen
                Schweiz

                Tel.: [phone]
                Fax:              -79

       Benchmark Modula-2 is available from:
                Armadillo Computing
                5225 Marymount Drive
                Austin, Texas 78723
                USA

                Phone/FAX: [phone].
                EMail: Jim Olinger, [e-mail]

  *Oberon*
  *Oberon-2*
       AmigaOberon is offered by A+L too. It is integrated into a full
       developers environment and has a large library of modules. Library
       linker and source level debugger are available. The AMOK user goup
       supports AmiOberon as well as M2Amiga.

  *Pascal*
       There is a PD-compiler called PCQ (Directory `dev/lang' on Aminet
       or Fish disk 511). It doesn't support all of Pascal and major
       features are missing. P2C, a pascal to C converter is on disk 341.
       (Aminet: `/dev/misc/p2c120.lha') Additionally there are two
       commercial compilers called HiSoft Pascal and KickPascal. HiSoft
       Pascal and P2C claim to be compatible to Turbo Pascal up to 5.0.
       HiSoft has a source level debugger included.

  3.6 Those never working Esc sequences!
  ======================================

     Many printers come with a manual that explains which Esc sequence
  causes which action on the printer. But there happen weird things when
  you try to send these sequences to your printer, either it does
  nothing, or it does something completely different. There is a reason,
  the Amiga printer drivers. These drivers are made in a way that they
  only understand a certain set of `ANSI Esc sequences', not the special
  ones defined (differently) by the various printer manufacturers. The
  purpose is that every application on the Amiga just uses this one
  standard set of control sequences and this way doesn't need to know
  which printer is actually connected. The printer driver then translates
  these standard sequences into the special sequences a certain printer
  understands.  A list of the available ANSI Esc sequences is found in
  the current Workbench manuals (or older AmigaDOS manuals). Now if you
  want to issue a control sequence to the printer that's not available as
  an ANSI command, you have two possibilities to achieve this:
    1. Bypass the printer driver (that would unsuccessfully try to
       interpret the sequence) and send your output *only* during this
       sequence to `PAR:' (or `SER:', respectively). For this you have to
       close and open printer output channels very often which is rather
       tedious, and you have to know where (`PAR:' or `SER:') your
       printer is connected.

    2. Use a special ANSI sequence, made exactly for this case:
                `Esc[<n>"<x>'
       where `<n>' is the decimally typed number of bytes in the string
       `<x>', which actually contains your special printer sequence. This
       ANSI sequence tells the printer driver to not interpret or
       translate the next `<n>' bytes.
          But both methods have one big disadvantage when used in an
  application program: You lose the printer independency! If you stick to
  ANSI sequen- ces, you can output to any printer on earth, as long as
  there is an Amiga printer driver for it. If you start to use special
  control sequences, your program will be tied to this single printer
  model and will not be usefull for any other (or you would have to
  provide some dozen new printer drivers for your application).

     Dr. Peter Kittel, [e-mail]

  3.7 Is it possible to use AmigaBasic on the A1200?
  ==================================================

     We heard conflicting reports about AmigaBasic on the A1200: While I
  said that you can work sufficiently with it, others said that this
  isn't possible, as AmigaBasic crashes on the slightest little error.  I
  couldn't reproduce this.

     Now I can. It depends on the setting in the Sound Prefs editor. When
  you activate a sound there, this conflicts with sound that AmigaBasic
  tries to produce by hand and obviously not quite the correct way itself.

     Easy solution: To work with AmigaBasic on the A1200, just
    1. Switch off sound output in the Sound prefs editor.

    2. On the A4000 (as well as on an A1200 with Fast Mem expansion (1))
       you  additionally need to run NoFastMem.

    3. Better avoid SUBs and use conventional GOSUBs instead, then the
       compatibility with newer processors will be higher.

     Dr. Peter Kittel, [e-mail]

     ---------- Footnotes ----------

     (1)  If you have a turbo board

  3.8 How do I localize my program?
  =================================

     Suggest, you want to write a `HelloLocalWorld.c'. Your final program
  will look like this:

           #include "HelloLocalWorld_Cat.h"
           #include <clib/exec_protos.h>

           struct Library *LocaleBase;

           void main(int argc, char *argv[])

           {
               /* Open the locale.library. No kill, if not successfull.
                  (Just use the builtin catalog strings instead.) Note, that
                  we open locale.library here, even if our compiler supports
                  AutoOpening.
               */
               LocaleBase = OpenLibrary("locale.library", 38);
               OpenHelloLocalWorldCatalogs(NULL, NULL);

               printf(GetString(MSG_Hello));

               CloseHelloLocalWorldCatalog();
               if (LocaleBase) CloseLibrary(LocaleBase);
           }

     The routine GetString checks, if the wished catalogs are available
  and returns a pointer to either the builtin string or the catalog
  string. (In my case the german string.)

     You see, the main difference besides the minor opening and closing
  stuff (OpenLibrary, OpenHelloLocalWorldCatalogs, ...) is to replace
  strings with a function call. Hence we need a file
  `HelloLocalWorld_Cat.c', which holds OpenHelloLocalWorld, GetString,
  CloseHelloLocalWorld and the builtin strings (this could be an array,
  where
               array[MSG_Hello] = "Hello, local world.\n";

  is defined) and an include file `HelloLocalWorld_Cat.h', which defines
  the message ID's like MSG_Hello. You don't need to know, how these files
  work internally, especially you don't need to know `locale.library'!

     There are some catalog generators (in what follows: CGs) available
  (`CatComp', for devlopers only, `KitCat', german docs only, `MakeCat',
  which I don't know and `FlexCat', which I  recommend, because it is
  most flexible in the generated source and supports catalogs on 2.0 and
  any language, even Amiga-E, Cluster, Pascal, ... and besides that: I'm
  the author ;-) are tools, that create  HelloLocalWorld_Cat.h,
  HelloLocalWorld_Cat.c and the real catalogs for you. (The above code
  might differ slightly between the different CGs.) (See Aminet, directory
  `dev/misc'.)

     Of course they need to know how to use them. First create a so-called
  `catalog-description' file. This could look like this:
           ; Lines beginning with a semicolon are comment lines.
           # language english
           ; the language of the builtin strings
           # version 0
           ; the catalog version (0 = any)
           MSG_Hello (1/15/30)
           Hello, local world

  Any string is defined by a line like the last two lines above: MSG_Hello
  is the message-ID, (1/15/30) says, that the value of MSG_Hello should be
  1 (you may omit this, in which case just the next free number is used)
  and the string must not be shorter than 15 characters or longer than 30
  characters. (These may be omitted too.)

     Now write your program. Once you are ready, use the CGs to create a
  so-called catalog translation file. (One for any language different than
  the builtin.) In my case (german) this could look like this:
           ; Lines beginning with a semicolon are comment lines.
           ## language deutsch
           ; the catalog language (german)
           ## version $VER: Deutsch.catalog 1.0 (22.12.93)
           ; the catalog files version string
           MSG_Hello

           ; Hello, local world

  Note the empty line after the message ID. (The arguments of ## language
  and ## version would be missing as well.) You have to fill in the
  german strings here. Again using the CGs you create a catalog file from
  this. Additionally note, that no informations on the strings ID or
  length are behind MSG_Hello.  They are taken from the catalog
  description file.

     Once you change the program (adding strings, changing the string
  length) you change the catalog description as well, use the CGs in the
  same way to update the catalog translation and hence the catalogs.

  3.9 How to obtain a pointer to a console's window
  =================================================

     The following function returns the window pointer of a CON window.
  It can be executed safely under all versions of the Amiga's OS.

         struct Window *getConWindowPtr(BPTR fh)
          {
          struct Window *w;
          struct FileHandle *cfh;
          struct StandardPacket *sp;
          struct InfoData *id;
          struct MsgPort *mp;

          w = NULL;

          if((cfh = BADDR(fh))->fh_Type != NULL)
           {
           if(sp = AllocMem(sizeof(struct StandardPacket),
                            MEMF_PUBLIC | MEMF_CLEAR))
            {
            if(id = AllocMem(sizeof(struct InfoData),
                             MEMF_PUBLIC | MEMF_CLEAR))
             {
             if(mp = CreatePort(NULL, 0))
              {
              sp->sp_Msg.mn_Node.ln_Name = (char *)&sp->sp_Pkt;
              sp->sp_Pkt.dp_Link         = &sp->sp_Msg;
              sp->sp_Pkt.dp_Port         = mp;
              sp->sp_Pkt.dp_Type         = ACTION_DISK_INFO;
              sp->sp_Pkt.dp_Arg1         = MKBADDR(id);

              PutMsg(cfh->fh_Type, &sp->sp_Msg);
              (void)WaitPort(mp);
              (void)GetMsg(mp);

              if(sp->sp_Pkt.dp_Res1)
               w = (struct Window *)id->id_VolumeNode;

              DeletePort(mp);
              }
             FreeMem(id, sizeof(struct InfoData));
             }
            FreeMem(sp, sizeof(struct StandardPacket));
            }
           }

          return w;
          }

     Notes:
     * Accessing a console's window directly may interfere with operations
       performed by the CON handler. Be careful!

     * To obtain the window pointer of a CLI's console, pass the
       FileHandle returned by Open("*", MODE_OLDFILE) to the above
       function.

     * The result of the above function may well be NULL, e.g. in case of
       an AUX handler or if an AUTO CON handler is unable to open its
       window.

     * Sending an ACTION_DISK_INFO packet to an AUTO CON handler (2.0+)
       causes its window to lose its special AUTO properties (i.e. it can
       no longer be closed at any time by clicking on its Close gadget),
       as the window pointer returned in id_VolumeNode must remain valid
       from now on.

     * All in all: Don't use this function. :-)

     For more information, please refer to pages 273, 276, 435, 463, 485,
  and 629 in "The Amiga Guru Book" (see Manuals).

     Ralph Babel, [e-mail]

  3.10 What are pragmas?
  ======================

     Pragmas are special preprocessor commmands which control certain
  features of a C-compiler. Two problems arise when using pragmas:
    1. Pragmas are compiler specific. You cannot expect that one compiler
       will understand pragmas of another compiler, even if both run on
       the Amiga.

    2. You are not guaranteed that a compiler ignores pragmas, that he
       doesn't understand. Even more: It might not help, to use something
       like this:
                #ifndef MY_COMPILER
                #pragma DoAnything
                #endif

  A workaround is to put pragmas in a special include file (BTW, the same
  holds true for statements like #asm (Aztec-C) or #extern (C++) and
  replace the above with
           #ifndef MY_COMPUTER
           #include <mypragmas.h>
           #endif

     But what do pragmas on the Amiga? The most common usage (not the
  only, but most meant when talking about pragmas) is to tell the
  compiler about how to call library functions: Simple C functions expect
  their arguments on the stack, but library functions want their
  arguments in special processor registers and additionally the `library
  base' in register a6. Lets have a look at a pragma command of the
  Aztec-Compiler.
           #pragma amicall(SysBase,0xd2,FreeMem(a1,d0))

  This tells the compiler to put the first argument of FreeMem in register
  a1, the second in register d0 and the value of the variable SysBase in
  register a6. Maxons pragmas look the same, Dice pragmas and SAS pragmas
  look a bit more complicated;
           #pragma libcall SysBase FreeMem d2 0902

  Here d2 is (like 0xd2 above) the `library vector offset' (see below),
  the digits 09 are codes for the argument register in reversed order
  (Register codes are 0=d0, 1=d1, .., 8=a0, 9=a1, a=a2, ..), the
  following 0 is the result's registerΣ(always d0))and the final digit 2
  is the number of arguments.

     A command `FreeMem(fib,sizeof(*fib);' could produce the following
  code, if the compiler has seen a pragma statement like above:
           move.l  _fib,a1
           move.l  260,d1        ; sizeof(struct FileInfoBlock)
           move.l  _SysBase,a6
           jsr     -0xd2(a6)       ; 0xd2 = _LVOFreeMem

  Calling FreeMem in that way is shorter and faster than pushing the
  arguments on the stack, calling a function _FreeMem which would do just
  the same like the above code by pulling the arguments from the stack.

     The best way to use pragmas is to include statements like the
  following in your program:
           /*    Get the prototype for the function; note, that this is    */
           /*    compiler independent.                    */
           #include <clib/exec_protos.h>

           /*    Get the pragma; compiler dependent, but most pragmas    */
           /*    are in files with the same name.
           #ifdef AZTEC_C
           #include <pragmas/exec_lib.h>
           #endif
           #if defined(__SASC) || defined(_DCC) || defined(__MAXON__)
           #include <pragmas/exec_pragmas.h>
           #endif
           #ifdef __GNUC__
           #include <inline/exec.h>
           #endif

  The above example can be compiled on all these compilers and produce the
  best code.

     A final question arises: How to get the pragmas? Most compilers have
  them included. However, sometimes you want to produce pragmas for
  yourself, for example if you are using new libraries or new versions
  with additional functions. In that case you can produce them from the
  so-called `FD' files which should be a part of the developer docs of
  the library. (The NDU has a directory FD which contains FD files for
  all libraries and devices of the OS. see Includes) Most compilers have
  a utility with the name `fd2pragma' or similar included which can do
  that for you. A freely distributable version which can produce pragmas
  for Aztec, Dice, SAS and Maxon as well as LVO files for assembler and
  stub routines for the tag versions is available on Aminet
  (`dev/misc/fd2pragma2_0.lha' and on the Fish CDs.

  3.11 Where do I find the function xxx?
  ======================================

     First ensure, that the function is really missing: For example
  floating point functions are in a special link library and you need a
  linker option like `-lm' to include it into your program. Another
  possibility would be that you are using a library function and didn't
  notice it. This might lead to a missing library base, `IntuitionBase'
  for example. In that case just put something like
           struct Library *IntuitionBase;

  somewhere in the global part of your program. (Don't forget to call
  OpenLibrary() and CloseLibrary! :-)

     However, you could as well use a function which really isn't present
  in your library at all. If you have, for example, an amiga.lib from 2.0
  you would hardly find the locale functions or the pool memory
  functions. (1) Best solution is to get the NDU (see Includes), but you
  probably don't want to wait for it. In that case you have to find what
  kind of function you are missing.
     * Simple library functions (Examples: `exec/AllocPooled',
       `locale/OpenCatalogA') can be called with pragmas. However, you
       need informations on the name of the library base and where to put
       the arguments. See Pragmas.

     * Tag functions are mostly just stub functions which call library
       functions. If you have, for example, `dos/AllocDosObject' which
       expects a constant and a pointer to an array of tags, you have the
       varargs version `AllocDosObjectTags' which expects tags on the
       stack as well! Just create the following function:
                #include <clib/dos_protos.h>
                #include <pragmas/dos_pragmas.h>    /*  Probably wrong name */

                void *AllocDosObjectTags(ULONG objtype, Tag tag1, ...)
                { return(AllocDosObject(objtype, (struct TagItem *) &tag1);
                }

     * Some functions still remain: Amiga.lib has some functions which
       are really doing valuable things and not just call a library: The
       BOOPSI functions (`DoMethod', `DoSuperMethod') the memory pool
       functions (`LibAllocPooled', `LibCreatePool', which are
       replacements of 3.0 functions). The only way to replace these is
       to get equivalents. The AmigaFAQ archive contains some of them
       (DoMethod, DoSuperMethod and HookEntry) in the `programmer'
       directory as well as the most common pragma files and some
       examples of varargs functions. See Amiga-FAQ Archive.

     ---------- Footnotes ----------

     (1)  This problem arises most frequently for owners of Aztec which
  is no longer supported and owners of Dice, which has sometimes rather
  incomplete libraries. I own both ...

  4 Applications
  **************

     This chapter offers informations about major Applications.

  4.1 Text Editors
  ================

     Text Editors are programs allowing to enter and edit unformatted
  text.  Generally, this means text that is meant to be manipulated by
  machine, rather than human. Programmers use these to enter the text for
  compilers.  Since UNIX machines don't typically have word processors,
  most text processing starts with a text editor, then is filtered
  through a page layout system (TeX, for example) to produce attractive
  paper results.

  *Commercial Products*
       CygnusEd Professional and TurboText seem to be the main contenders
       in the professional realm. The Fred Fish disks contain dozens of
       other shareware text editors. A demo version of TurboText is on
       Fish disk 445.  A very old demo of CygnusEd is on Fish disk 95
       (testament to its lasting-power). In the following some freely
       distributable editors will be discussed.

  *Emacs*
       Gnu Emacs (the "G" is not silent) comes from Unix and is probably
       the king of editors - it's huge (about 1 Megabyte), feature-packed
       (it does windows and even contains a game!) and extensible (if you
       know lisp you can write new emacs functions and bind them to any
       key combination).  On the other hand, it may be too huge, its
       feature-ladenness is imposing, and its extensibility often means
       you can't use someone else's emacs configuration. Source: Aminet
       (directory `util/gnu').

  *Vi*
       The leaner, less configurable, non-extensible cousin to gnu emacs
       is vi (pronounced "vee eye"). Unix people like vi especially
       because you find it on *any* Unix machine. What you choose is
       personal preference, and will mark you for life. Vim is a good vi
       for the amiga, and is on Fish disk 591 or in the `util/gnu'
       directory of Aminet.

  *DME*
       Many Amiga programmers like DME. It's fast, fully configurable;
       menus may be created and any key may be mapped. It's much easier
       to learn DME than than Emacs or Vi. There are three different
       versions: AmokEd, DME and XDME. It's a matter of opinion which you
       prefer. (Oberon and Modula programmers like AmokEd because it's
       written in Oberon and supports AmiOberon error messages, C
       programmers like DME or XDME.) Sources: Aminet (directory
       `util/edit'), Fish disk 776 (XDME) and 749 (AmokEd), AMOK 90.

  4.2 What word processors are there?
  ===================================

     A word processor is the typical application for writing notes,
  letters or reports on a computer. Unless you prepare newsletters on a
  weekly basis, your word procesor is probably your workhorse program.
  Thus choosing one you are comfortable with determines how comfortable
  you are with your computer. Word processors can offer a variety of
  features, and many can approach the sophistication required for Desktop
  Publishing (see DTP) but no one uses them for programming, for which
  text editors are more suited.

     One distinguishes between Wysiwyg programs (What you see is what you
  get) and page layout languages. Wysiwyg programs should be fast,
  comfortable and easy to use. Most people prefer them. The alternative
  is an approach that works similar to compilers. You feed text files to
  a a program that produces the layout which may be previewed on screen
  or printed. LaTeX takes this approach. See TeX. Lout is another such
  system which seems smaller, easier to learn and has full documentation
  included, but it is nonstandard.  Lout produces Postscript output. (I
  don't know if this is an advantage or disadvantage. ;-) See Postscript.
  Both programs are freely distributable.

     There are a lot of wysiwyg programs, but only commercial products:
  Final Copy II, Wordworth, Word Perfect, AmiWrite, Beckertext II, Maxon
  Word and many others. I don't dare to recommend any. ALl I can say is:
  Give yourself time to make a selection.

  4.3 Desktop Publishing
  ======================

     These programs offer features lacking in word processors, usually
  tailored to flexible arrangement of text, but often don't provide all of
  the text manipulation that a good word processor provides. The best
  desktop publishing programs strive to provide the features of both,
  just as the best word processors strive to provide the features of
  desktop publishing programs. Microsoft Word (Mac, PC) is a good example
  of a word processing program that offers many page layout feature.
  Framemaker (UNIX, Macintosh, DOS, etc.) is an example of a desktop
  publishing system that offers most needed word processing functions. As
  yet, no Amiga program has bridged the gap, though the main word
  processors are coming close. (On the other hand, even many
  sophisticated programs don't support typesetting mathematics, tables,
  producing bibliographies, indexes, or cross-references. The page layout
  languages do, and programs like Frame are improving their support of
  such features.) Unless you need to prepare fancy newsletters or
  promotional literature, a word processing program is probably enough.
  See Word Processors.

     There are not yet any freely distributable wysiwyg desktop publishing
  systems. Commercial products are ProPage and PageStream. They have been
  playing leapfrog for the past few years. It appears that PageStream 3.0
  is about to leap ahead. A more detailed description of these products
  and their differences is welcome. Both programs' list prices are $299.
  Student discounts are available (approx 40% discount.)

  4.4 What is TeX and where can I get it?
  =======================================

     TeX is a very powerful wordprocessing system. It can display
  mathematical formulas or complex tables as well as function graphs,
  creates indices, contents and many other things. Its greatest advantage
  is that it is freely distributable (TeX, not the previewers and the
  printer drivers!) and that you find TeX all over the world on every
  computer family. Its greatest disadvantage is that it isn't very handy
  (works similar to a compiler) and it isn't wysiwyg. But many people
  like it. (BTW: This document is written using TeX. 8-) See Word
  Processors.

     There are two major implementations on the Amiga. The first one,
  Amiga-TeX, from Thomas Rockicki and Radical Eye software is commercial.
  It is said to be excellent and his owners seem to be very satisfied.
  But it costs at least 200$.

     I recommend PasTeX, a freely distributable version. People seem to
  have problems installing PasTeX, especially the font loading and
  generation (It's a quite complex program.) but I did not here anyone
  upset once it was installed. (A friend with knowledge of TeX helps
  immensely.) A few words should be said what you need:
     * 5 disks containing the TeX-compiler itself

     * 2 disks containing MetaFont

     * Nothing more Many people ask for fonts. They are included in the
  MetaFont-package and can get compiled by you. All you need to do is
  setting up your TeX-system in the right way which is described in the
  documentation. Please note that the PasTeX disks are compressed using
  the program Zoom. (see Endings) Sources: FTP at `ftp.uni-passau.de',
  directory `/pub/amiga/tex/PasTeX1.3'.

  4.5 Are there any Postscript interpreters?
  ==========================================

     PostScript is a programming language designed to be used to describe
  printing on pages. Apple helped make PostScript popular by selling
  printers with built in PostScript interpreters. Many programs have
  evolved to produce PostScript programs as their output, making
  PostScript the lingua franca of printing. Until recently, in order to
  print a PostScript file, you had to have a relatively expensive laser
  printer. The development that changed this was the software PostScript
  interpreter. These programs allow your computer to interpret PostScript
  programs, and produce the matrix of dots to send to your normal
  graphics printer.

     One of the benefits of PostScript is that it is resolution
  independent.  What this means is that it can support the highest
  resolution of your device - and that you can reasonably preview
  PostScript on a low resolution screen.

     There are two free PostScript interpreters for the Amiga. Post and
  Ghostscript. Post comes as an Amiga shared library along with front
  ends for previewing to the screen and printing. This structure allows
  others to write programs that can show PostScript images on screen. In
  fact, AmigaTeX uses Post's library to support incorporation of
  PostScript into documents.  Ghostscript similarly comes in two
  programs, but not as a shared library.  Ghostscript is the rendering
  engine, and Ghostview is the front end.  Sources: Aminet (directorys
  `text/print' and `text/dtp'), Fish disk 669

--
Jochen Wiedmann            E-Mail: [e-mail]